home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0990.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  4.2 KB  |  126 lines
  1.  
  2. Dave,
  3.     O'Reilly and Associates is *extremely* interested in helping you with
  4. this effort.  We have a number of products in development which use HTML as
  5. their technology base.  We see the future development of HTML to be of great
  6. importance to our efforts.
  7.  
  8.     You mention the following as important issues in the future of HTML:
  9.  
  10. <QUOTE AUTHOR="Dave_Raggett <dsr@hplp.hpl.hp.com>">
  11.     o   nested lists (e.g. OL within UL, UL within DL, ...)
  12.     o   embedded images with text flow etc.
  13.     o   query forms
  14.     o   tables
  15. </QUOTE>
  16.  
  17.     I would suggest that lists and text flow are really exclusively
  18. rendering issues.  When I want to make a nested list, I may wish to write it
  19. thusly:
  20.  
  21. <EXAMPLE>
  22.     <UL>
  23.     <LI>First Term, First Level.
  24.     <UL>
  25.     <LI>First Term, Second Level.
  26.     <LI>Second Term, Second Level.
  27.     </UL>
  28.     <LI>Second Term, First Level.
  29.     </UL>
  30. </EXAMPLE>
  31.  
  32.     And I might *EXPECT* that it would be rendered as:
  33.  
  34. <PRE>
  35.         First Term, First Level
  36.             First Term, Second Level
  37.             Second Term, Second Level
  38.         Second Term, First Level
  39. </PRE>
  40.  
  41.     
  42. <COMMENT> And in fact, under Xmosaic, the *right* thing is done, with the
  43. addition of some nice bullets to differentiate the different levels of the list.
  44. </COMMENT>
  45.  
  46. But since there is no rendering information in HTML, and by definition there
  47. cannot be, how the terms appear on the screen is left up to the renderer.  For
  48. example, the www text mode browser renders these lists thusly: 
  49.  
  50. <PRE>
  51.         First Term, First Level.
  52.       
  53.         First Term, Second Level.
  54.       
  55.         Second Term, Second Level.
  56.       
  57.         Second Term, First Level.
  58.      
  59.         [End]
  60. </PRE>
  61.  
  62.     Since there is no definition of how things *must* look when presented to
  63. the user, both behaviors are absolutely correct.
  64.  
  65. <HYPOTHESIS> Any expectations of how an object is rendered will be incorrect in
  66. some instance of the use of that object.  Thus, all expectations of an object's
  67. appearance are generally inadvisable.  </HYPOTHESIS>
  68.  
  69.     I would also suggest that the requirements of 'text flow' around
  70. embedded graphics are also rendering time issues and should not effect the
  71. definition of HTML. 
  72.  
  73. <OPINION> I believe that HTML, like it's progenitor SGML, should be simply a
  74. method of describing data, not how it should appear on the screen.  In fact, I
  75. think that this is exactly the sentiment which Tim Berners-Lee has expressed to
  76. us all regarding his vision of HTML. The formatting of lists and the flow of
  77. text around graphics do not fit this definition.  If this is an incorrect
  78. assessment of the role HTML needs to serve I would be very interested in hearing
  79. from others. </OPINION>
  80.  
  81.     The next elements on your list, query forms and tables, seem to be a
  82. little clearer but pose similar problems. 
  83.  
  84.     To describe a "form", in the traditional sense, implies it's layout
  85. simply based on the fact that a "form" is the presentation of information in a
  86. controlled layout or format.  
  87.  
  88. <HYPOTHESIS> A form or table cannot be specified in HTML without breaking one of
  89. HTML's first principles since forms and tables are descriptions of the
  90. appearance of information in relationship to other elements and not the
  91. description of information in terms of type and content. </HYPOTHESIS>
  92.  
  93. I believe that we can ask questions:
  94.  
  95. <EXAMPLE>
  96.     <QUERY DEFAULT="Red" OPTIONS="Black|Blue|Red|Green|White">
  97.     What is your favorite colour?
  98.     </QUERY> 
  99. </EXAMPLE>
  100.  
  101. since this is the tagging of an entity (description of data), with certain
  102. special behaviors or attributes defined, I would think that this would be a
  103. natural for HTML.
  104.  
  105. But, the moment we start talking about collecting this information into forms or
  106. tables, with set, defined  relationships between elements, we are treading on
  107. very thin ice, indeed. 
  108.  
  109. <ASIDE> I hesitate to mention it, but SGML has few (if any) provisions for
  110. handling tabular data, and there are a lot of people who really want to be able
  111. to do this, desperately! </ASIDE>
  112.  
  113. <ASSERTION> The organization of information into tabular form is intrinsically a
  114. render-time issue, not a representational one. </ASSERTION>
  115.  
  116.  
  117.     I am very interested in these issues, both from a personal standpoint
  118. and a company one.  I have some ideas regarding a possible solution which I will
  119. send out under seperate cover.  Thanks for your time.
  120.  
  121.  
  122.  <SIGNATURE>    Rob Raisch, O'Reilly & Assoc.    </SIGNATURE>
  123.  
  124.  
  125.  
  126.